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Abstract.  The  boundaries  of  systems  engineering  are  evolving  as  system  related  needs 
evolve.  These  ‘fuzzy’  boundaries  result  in  gaps  between  what  users  in  the  systems 
engineering  community  need  and  what  the  body  of  knowledge  of  systems  engineering 
provides.  This  paper  covers  various  use  cases  of  the  body  of  knowledge  of  systems 
engineering  and  explores  gaps  in  the  existing  knowledge  base  in  two  areas:  1)  related 
disciplines,  and  2)  emerging  systems  engineering  topics. 

Introduction 

The  body  of  knowledge  of  systems  engineering  covers  the  development  of  engineered 
systems  that  are  created  by  and  for  people.  These  systems  have  a  purpose  within  multiple 
perspectives  and  satisfy  key  stakeholder  needs.  Each  system  also  has  a  context  within  which 
it  exists  in  an  external  environment,  as  well  as  in  internal  organization  that  many  times 
determines  its  level  of  efficiency  and  effectiveness.  Systems  are  also  typically  part  of  a 
system-of-interest  hierarchy.  This  paper  explores  the  relationship  of  a  particular  body  of 
knowledge,  the  Guide  to  the  Systems  Engineering  Body  of  Knowledge  (SEBoK)  (Pyster,  et. 
al  2011)  and  areas  where  the  body  of  knowledge  falls  short  of  meeting  the  needs  of  the 
systems  engineering  community.  These  shortfalls  have  been  uncovered  through  the  efforts  of 
both  the  SEBoK  and  Graduate  Reference  Curriculum  in  System  Engineering  (GRCSE™) 
authors  (represented  by  the  authors  of  this  paper)  and  the  efforts  of  reviewers,  specifically 
those  who  reviewed  versions  0.25  and  0.5  of  the  SEBoK.  While  this  list  of  shortfalls  is  not 
necessarily  complete,  the  list  will  be  modified  based  on  both  the  efforts  of  the  authors  for 
versions  0.75  (released  in  March  2012)  and  1.0  (to  be  released  in  September  2012)  based  on 
feedback  received  from  authors  and  reviewers  of  these  products. 

Background 

As  described  in  Squires  et  al.  (2009),  the  Body  of  Knowledge  and  Curriculum  to  Advance 
Systems  Engineering  (BKCASE™)  project  is  a  three-year  effort  initiated  in  September  of 
2009  to  produce  two  version  1.0  products:  a  Guide  to  the  Systems  Engineering  Body  of 
Knowledge  (SEBoK)  and  a  Graduate  Reference  Curriculum  in  System  Engineering 
(GRCSE™).  The  project,  primarily  funded  by  the  U.S.  Department  of  Defense,  is  led  by  a 
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university  partnership  between  the  Stevens  Institute  of  Technology  and  the  U.S.  Naval 
Postgraduate  School  (NPS)  with  support  from  various  professional  societies,  especially  the 
International  Council  on  Systems  Engineering  (INCOSE)  and  the  Institute  of  Electrical  and 
Electronics  Engineers  (IEEE),  along  with  other  universities  and  companies  who  provide  and 
support  about  70  BKCASE  authors  from  around  the  globe.  A  series  of  articles  updating  the 
status  of  the  project  from  2009  through  2011  are  available  from  dwell  et  al.  (2010),  Squires 
et  al.  (2010),  Roussel  et  al,  (2011)  and  Squires  et  al.  (2011). 

Adcock  et  al  (2011)  focused  on  research  gaps  in  the  initial  version  0.25  of  the  SEBoK.  This 
paper  expands  that  gap  analysis  using  the  perspective  of  interrelationships  with  related 
disciplines  and  emerging  systems  engineering  topics.  The  most  current  SEBoK  version  0.75 
can  be  found  at  sebokwiki.org  (Pyster,  et.  al.,  2011);  however,  this  analysis  began  with  version 
0.5,  and  the  most  current  available  version  0.75  addresses  some  of  these  findings.  The  goal  is 
to  address  additional  areas  in  the  final  version  1.0  to  be  released  in  September. 

Use  Cases 

The  SEBoK  is  intended  to  inform  systems  engineering  practice,  research,  curriculum 
development,  certification,  organizational  strategy,  and  related  disciplines.  Users  of  the 
SEBoK  include  practicing  systems  engineers,  process  engineers,  faculty  members  and 
curriculum  developers,  systems  engineering  trainers  and  certifiers,  engineering  managers, 
hardware  engineers,  software  engineers,  project  managers,  and  customers  of  systems 
engineering  products  and  services.  The  SEBoK  currently  describes  use  cases  for  several  types 
of  users;  however,  these  are  high-level  descriptions  that  will  need  to  evolve  into  detailed 
roadmaps  that  can  be  used  to  quickly  navigate  the  SEBoK  based  on  immediate  and 
longer-term  needs.  As  these  use  cases  evolve,  the  gaps  in  the  body  of  knowledge  will 
become  more  apparent.  In  the  meantime,  the  two  main  areas  of  focus  are  related  disciplines 
and  emerging  topics,  each  of  which  are  addressed  in  the  next  two  main  sections. 

Related  Disciplines 

The  SEBoK  represents  the  best  efforts  of  a  large  community  of  systems  engineers  to  define 
the  topics  that  comprise  the  discipline  of  systems  engineering.  As  part  of  that  definition,  the 
authors  struggled  with  the  relationship  of  systems  engineering  to  related  disciplines  such  as 
hardware  engineering,  software  engineering,  project  management  and  engineering 
management.  The  team  discovered  that  stakeholders  from  the  systems  engineering  and 
related  communities  draw  the  boundaries  between  these  disciplines  differently.  In  addition, 
there  was  a  disagreement  among  systems  engineering  experts  as  to  which  related  disciplines 
were  of  key  importance  versus  those  that  were  not.  Topics  often  were  included  in  two  or 
more  of  these  overlapping  disciplines,  and  the  boundaries  were  fuzzy. 

The  SEBoK  authors  decided  to  limit  the  number  of  duplicate  topics  in  bodies  of  knowledge 
developed  by  other  disciplines,  notably  the  Project  Management  Body  of  Knowledge 
(PMBoK)  (PMI,  2008)  and  the  Software  Engineering  Body  of  Knowledge  (SWEBoK) 
(Abran  and  Moore,  2004).  This  led  to  some  difficulty,  as  the  approach  and  content  of  an 
article  on  software  engineering  written  for  a  software  engineer,  for  example,  may  be 
substantially  different  in  scope  and  depth  from  an  article  written  for  a  systems  engineer  on 
the  same  topic,  which  might  have  a  much  greater  management  and  integration  emphasis. 
Thus,  in  some  parts  of  the  SEBoK  it  was  necessary  to  include  knowledge  areas  and  topics 
that  have  duplicate  topical  coverage,  but  present  the  information  from  a  systems  engineering 


perspective.  Relationships  of  systems  engineering  to  other  disciplines  is  also  addressed  in 
Part  1  of  the  SEBoK  in  a  general  way.  However,  there  are  some  gaps  in  the  areas  of  the 
SEBoK  related  to  other  disciplines,  in  general.  Areas  of  interest  to  systems  engineers  in 
hardware  and  software  engineering,  project  management,  as  well  as  industrial  engineering, 
procurement  and  acquisition,  and  emerging  specialty  disciplines  are  explored  specifically  in 
the  following  sections. 

Hardware  and  Software  Engineering 

The  relationship  of  systems  engineering  to  hardware  engineering  is  a  classical  relationship 
that  has  stood  the  test  of  time.  In  this  way,  systems  engineering  has  supported  the  integration 
of  the  traditional  engineering  disciplines  of  electrical,  mechanical,  civil,  aeronautical  and 
others,  that  have  historically  been  based  in  hardware.  The  relationship  of  systems  engineering 
to  these  disciplines  is  so  ingrained  that  many  believe  systems  engineering  to  be  the  actual 
integration  of  these  disciplines  -  or  multidisciplinary  in  nature  and  definition.  In  this  way  a 
multidisciplinary  engineer  is  synonymous  with  systems  engineer. 

The  argument  has  been  made  that  software  is  no  different  than  any  other  discipline  relative  to 
systems  engineering.  However,  as  more  and  more  of  the  control  functions  of  systems  is 
embodied  in  software,  systems  engineers  are  required  to  interact  with  more  software  oriented 
team  members  and  understand  systems  that  are  more  and  more  software  intensive  in  their 
development.  There  are  two  distinct  perspectives  that  need  to  be  well  understood  by  systems 
engineers.  First  there  are  the  aspects  of  software  as  a  component  of  systems  that  are  simply 
different  than  other  types  of  components.  Just  as  mechanical  systems  requirements  have 
physical  vibration  and  load  requirements,  software  requires  treatment  specific  to  software 
such  as  platform  and  operation  execution  time.  System  engineers  need  to  know  about 
managing  and  interacting  with  software  teams. 

For  hardware  and  software  Engineering,  there  are  fundamental  concepts  of  design 
development  and  architecture  that  every  SE  involved  with  systems  should  understand  in  order 
to  function  in  these  environments.  In  particular,  a  systems  engineer  should  understand 
common  architectures  and  design  patterns.  A  system  engineer  should  have  a  basic 
understanding  of  the  tools  and  models  used  to  design  and  develop  systems.  Many  projects 
have  failed  due  to  systems  integration  issues  associated  with  underestimating  the  complexity 
of  defining  and  managing  interfaces.  These  interfaces  are  also  one  of  the  areas  where 
security  vulnerabilities  are  most  common.  Since  hardware  and  software  must  often  be 
developed  and  tested  in  simulated  environments  a  systems  engineer  must  understand  the 
limitations  of  such  testing.  Knowledge  areas  with  which  a  systems  engineer  should  be  at 
least  conversant  include: 

•  Architectures  and  design  patterns,  and  their  implications  for  the  system  life  cycle 

o  Open  architecture:  issues,  strategies,  risks,  costs,  benefits, 
o  Interfaces  and  interface  management 

•  Cyber  security  issues,  assurance,  strategies,  and  costs 

•  Hardware  and  software  development  methodologies  and  tools 

o  Model  driven  software  development 
o  Resilient  SW 
o  Agile  SW 


•  Information  management  and  modeling  concepts  and  tools 

o  Data  rights 
o  Data  modeling 

•  Hardware  and  software  deployment  platforms  and  issues 

o  Real  time  embedded  systems 
o  Standards  based  Operating  Systems 
o  Standards  based  Data  Management  Systems 
o  Standards  based  Middleware 

•  Maturity  models 

o  CMMI 

•  Verification  and  Validation  of  hardware  and  software 

o  Simulation  of  performance 
o  Benchmarks 

•  Systems  of  systems  environment:  issues  and  strategies. 

•  Current  issues  and  advances  in  engineering 

Project  Management 

The  Systems  Engineering  Management  Knowledge  Area  of  the  SEBoK  addressed  Planning, 
Assessment  and  Control,  Risk  Management,  Configuration  Management,  Measurement, 
Quality  Management,  and  Infonnation  Management.  The  Knowledge  Area  explores  the 
topics  from  a  systems  engineering  technical  perspective  and  from  the  systems  engineer’s 
responsibility  to  supplement  and  collaborate  with  PM.  The  SEBoK  version  0.5  also  address 
the  relationship  between  systems  engineering  and  project  management  through  the  Systems 
Engineering  Management  Plan  (SEMP).  However,  there  has  been  an  extensive  amount  of 
research  documented  about  the  importance  of  the  chief  systems  engineer  and  the  project 
manager  to  be  ‘joined  at  the  hip’.  From  a  high  level  perspective,  the  project  manager  and  the 
chief  engineer  share  many  of  the  same  responsibilities  around  planning,  estimating,  risk 
management,  leading  and  directing,  and  measuring  and  controlling.  Both  are  responsible  for 
cost,  schedule  and  the  technical  success  of  the  project.  The  main  difference  is  typically 
viewed  as  the  project  manager’s  focus  is  on  cost  and  schedule  where  the  chief  systems 
engineer’s  focus  is  on  technical.  Yet,  project  success  requires  the  success  of  all  three  project 
attributes.  Also,  on  smaller  projects  the  same  person  may  carry  out  the  role  of  project 
manager  and  systems  engineer.  On  large  complex  projects,  a  team  may  be  needed  to  support 
each  role.  From  a  body  of  knowledge  perspective,  it  is  important  to  provide  the  systems 
engineering  community  with  common  practices  in  these  areas  related  to  roles  and 
responsibility  expectations  and  accountability  demands.  Systems  engineers  need  to  be 
accountable  not  only  for  the  technical  system  solution  but  also  for  the  total  ownership  cost  of 
the  system.  Understanding  technical  management,  risk  analysis,  decision-making, 
configuration  management,  and  many  other  areas  that  also  fall  into  the  realm  of  the  project 
manager  are  important  areas  needed  to  support  high  quality  systems  engineering. 

Other  Specialty  Disciplines 

Other  obvious  disciplines  to  include  in  the  discussion  of  systems  engineering  is  industrial 
engineering  and  procurement  and  acquisition.  Clear  distinction  between  emerging 
characteristics  of  systems  (see  Emerging  Topics),  including  many  of  the  more  recent 


specialty  engineering  topics.  Until  recently,  the  specialty  engineering  topics  were 
hand-picked  for  inclusion  in  the  SEBoK.  As  characteristics  emerge  or  become  more 
prominent,  we  need  to  identify  and  define  the  set  of  key  design/decision 
characteristics/criteria  currently  of  greatest  concern  (e.g.,  resilience,  robustness,  trusted 
systems,  system  assurance,  adaptability,  flexibility,  etc..).  However,  it  is  not  enough  to 
define  each  from  only  its  own  perspective.  We  need  to  define  the  relationships  between  the 
characteristics  and  their  level  of  independence.  And  then  provide  guidance  on  their  priorities 
under  which  system/operating  conditions. 

Emerging  Topics 

The  SEBoK  has  primarily  focused  on  the  portion  of  the  body  of  knowledge  that  has  solid 
roots  in  theory  and  application.  However  there  are  many  emerging  topics  in  systems 
engineering.  Many  of  these  are  seen  today  in  the  university  and  industry  research,  advances 
in  technology  and  tools,  and  further  integration  with  related  disciplines.  The  following 
provides  a  set  of  topics  that  fit  into  the  Emerging  SE  area  that  reflect  to  some  extent  gaps  in 
the  SEBoK.  Whereas,  a  few  of  these  topics  are  covered  in  the  SEBoK,  they  are  topics  that  are 
still  developing,  but  have  a  solid  foundation  with  reasonable  application.  These  can  be 
divided  into  the  areas  of: 

1 .  SE  Efficiency  and  Responsiveness 

2.  Architecture  Reuse  and  Efficiency 

3.  Model-based  SE 

4.  Complex  systems  and  System-of-Systems  (SoS)  Analysis 

5.  System  Affordability 

6.  SE  Measurement  Evolution 

7.  Total  system  solution  perspective 

8.  Advanced  Methods  of  Understanding  Stakeholder  Needs 

Each  of  these  is  explored  in  more  detail  in  the  following  sections. 

SE  Efficiency  and  Responsiveness 

SE  Efficiency  and  Responsiveness  involves  the  “right-sizing”  and  work-flow  planning  of 
systems  engineering  based  on  the  characteristics  and  risks  of  the  project  and  the  timing 
requirements  to  get  the  capabilities  to  the  user.  These  approaches  incorporate  principles  of 
lean  practices,  agile  development,  Kanban,  risk  management,  and  decision  management. 
This  focus  is  being  driven  by  the  need  to  reduce  time  for  delivery  of  key  capabilities  to 
customers  and  are  being  developed  to  address  the  following  situations:. 

Expedited  SE.  Expedited  SE  covers  situations  where  SE  is  focused  on  full-scale  life  cycle 
needs,  but  emphasizes  cost  effectiveness  and  efficiency  to  decrease  the  time  without 
sacrificing  the  necessary  level  of  rigor.  Expedited  SE  needs  to  be  able  to  address  changing 
operational  needs/threats  and  innovation/advances  in  technology  across  the  life  cycle  through 
a  risk  managed  approach.  There  is  research  currently  being  perfonned  under  the  SE  Research 
Center  (SERC)  on  this  topic,  as  well  as  a  means  to  incorporate  Kanban  approaches  to 
scheduling  the  SE  activities  based  on  value. 

Rapid  Fielding.  In  this  situation,  there  is  a  short  time  to  market  requirement  for  first  delivery 
of  the  most  critical  or  desired  capability.  That  is,  the  developed  system  must  meet  a  short 


timeline  to  field  the  capability,  and  the  resulting  system  may  be  a  one-time  implementation  or 
an  evolutionary  and  ongoing  development. 


Rapid  Response.  In  this  case  the  situation  requires  systems  engineering  as  a  service  in  a 
rapid  response  to  provide  systems  engineering  services  as  needed. 

Architecture  Related  Topics 

In  too  many  new  systems,  the  architecture  development  starts  from  scratch  without 
consideration  for  previous  architecture  definitions.  Although  this  allows  for  incorporation  of 
new  technology,  it  ignores  the  efficiencies  of  reuse  and  the  maturity  of  proven  architectures. 
In  many  cases  the  system  is  a  variant  within  a  product  line.  In  these  cases,  there  are 
significant  efficiencies  to  be  gained  by  recognizing  the  potential  variants  and  designing  in  the 
right  adaptability.  The  following  are  key  elements  that  allow  the  Systems  Engineers  and 
Architects  to  better  leverage  reusable  architectural  elements  for  both  efficiency  and 
effectiveness.  These  should  also  help  in  the  SE  responsiveness  discussed  above 

Platform  based  engineering.  This  considers  how  to  provide  adaptability  through  the  use  of 
flexible  platforms  that  can  account  for  variations  and  evolution  of  mission  needs.  This  can 
include  the  use  of  Product  Line  Architectures  (PLAs)  that  are  created  with  a  range  of 
potential  variations  in  mind. 

Reuse  of  system  definition  elements.  This  employs  the  identification  and  definition  of 
architecture  patterns,  reference  architectures,  and  architecture  frameworks  to  allow  leverage 
of  proven  architecture  elements  in  order  to  reduce  effort  while  improving  quality  and 
consistency. 

Addressing  architecture  from  both  top  down  and  bottom  up.  This  includes  the  use  of 

building  block  concept,  i.e.,  integration  of  well-designed,  configurable  system  elements 
within  an  architecture  framework. 

Pattern  Based  Architecture.  This  addresses  the  use  of  proven  architecture,  architectural 
elements,  or  patterns  to  streamline  the  development  of  new  architectures. 

Model-Based  SE 

The  true  power  of  modeling  and  simulation  to  support  SE  across  the  life  cycle  is  still 
emerging.  Model-based  SE  is  addressed  in  the  SEBoK,  but  is  still  very  early  in  its 
application,  especially  to  address  full  life  cycle  needs.  When  the  data  integration  needs  can 
be  adequately  addressed,  the  application  of  Model-Based  SE  will  likely  become  more 
widespread  and  mature.  The  SEBoK  addresses  some  aspects  of  models  and  modeling,  but 
does  not  reveal  the  full  potential  of  Model-based  SE  as  discussed  in  the  Final  Report  of  the 
Model  Based  Engineering  Subcommittee  of  the  National  Defense  Industrial  Association 
(NDIA)  (NDIA,  February  2011). 

Complex  Systems  and  SoS  Analysis 

Complex  systems  and  SoS  analysis  are  covered  to  some  extent  in  the  SEBoK,  but  are  still 
emerging  with  respect  to  the  application  and  knowledge.  The  analysis  and  management 
necessary  for  such  complex  systems  and  systems-of-systems  are  also  still  emerging  (see 


ODUSD(A&T)SSE,  2008).  The  analysis  and  management  of  these  systems  are  being 
considered  for  exploration  in  the  SEBoK  per  the  items  listed  below. 


Multivariate  analysis.  These  systems  have  many  variables  to  balance  and  needs  the 
development  of  cost-effective  and  efficient  means  to  perform  multivariate  analysis  to  support 
trades  for  the  growing  array  of  key  characteristics. 

SoS  Portfolio  Management.  As  the  SoS  evolves,  it  becomes  more  important  to  establish 
some  management  of  the  portfolio  of  systems  that  compose  it.  This  is  often  a  challenge  due 
to  the  independent  governance  of  those  systems.  The  management  of  the  portfolio  of  systems 
in  a  SoS  requires  cooperative  governance  to  evolve  capabilities  most  efficiently  -  e.g.,  evolve 
capabilities  across  the  set  of  systems  versus  creating  a  new  system  and  managing  the 
interface  and  interoperating  functions  that  may  involve  multiple  systems. 

Emergent  properties.  One  of  the  challenges  in  managing  the  Complex  System/SoS  is  the 
high  likelihood  of  emergent  properties.  It  is  essential  to  develop  effective  practices  for  the 
management  of  emergent  properties/requirements  to  ensure  acceptable  and  useful  evolution 
of  the  Complex  System/SoS  and  the  relevance  of  the  solution. 

System  Affordability 

There  is  a  growing  emphasis  on  system  affordability  (i.e.,  value  across  the  life  cycle).  The 
SEBoK  does  not  currently  provide  a  recognizable  thread  regarding  affordability  through  the 
set  of  Knowledge  Areas  and  Topics.  With  the  increasing  focus  on  the  cost  and  value  of  the 
system  across  the  total  life  cycle,  new  activities  or  changes  to  existing  activities  need  to  be 
identified  and  defined  to  ensure  affordability  becomes  part  of  the  mindset.  Operability  and 
supportability  are  becoming  more  important  in  the  government  arena  -  changing  analysis  and 
decision  models. 


SE  Measurement  Evolution 

Measurement  for  SE  has  been  evolving  significantly  over  the  past  several  years  (NDIA, 
October  2011).  While  SE  Measurement  is  a  topic  in  the  SEBoK,  this  topic  will  continue  to 
evolve  with  the  emerging  topics  of  SE  and  lessons  are  learned  from  the  application  of  recent 
developments.  New  measures  and  measurement  analysis  for  emerging  areas  and  key 
characteristics  are  needed  and  currently  being  explored.  SE  leading  indicators  have  been 
defined  and  are  being  leveraged  for  greater  insight.  Yet,  there  is  a  need  to  link  cost  and 
schedule  in  EVM  to  technical  performance,  including  1)  work  products  passing  reviews,  2) 
accomplishments  of  TPM  milestones,  3)  verification  of  system  requirements,  and  4) 
validation  of  stakeholder  needs.  Additionally,  advancements  in  SE  measurement  are  needed 
to  provide  necessary  insight  for  affordability,  as  well  as  some  of  the  other  topics  discussed 
above. 


Total  System  Solutions 

Related  to  the  total  system  solution  perspective,  there  is  an  increasing  realization  that  system 
solutions  need  to  consider  much  more  than  the  system-of-interest  itself.  Concurrent 
engineering  of  the  system-of-interest,  enabling  systems  (new  or  modified  to  support  SOI), 
and  interfaces/interoperability  with  known  and  potential  systems  in  the  operating 


environment  comprise  the  scope  for  the  total  system  solution  (ISO/IEC/IEEE  15288:2008(E). 
2008;  ISO/IEC/IEEE  24748-1,  2010). 

Advanced  Methods  of  Gathering  Stakeholder  Needs 

Recent  research  in  the  area  of  advanced  methods  of  understanding  stakeholder  needs  is  very 
promising  and  includes  areas  such  as  one  in  concept  engineering  that  explores  graphical  or 
virtual  ConOps  and  OpsCons  and  allows  interactive  involvement  of  stakeholders  in  a  fully 
immersive  environment  where  the  stakeholders  can  explore  concepts  and  their  feasibility 

Forward  Plan 

Based  on  ongoing  gap  analyses  such  as  this  paper  and  the  previous  work  by  Adcock  et  al. 
(2011),  the  BKCASE  team  plans  to  continue  to  expand  on  the  topics  covered  in  the  SEBoK 
for  the  final  version  1.0  release  in  September  2012.  Following  this,  two  professional 
societies,  the  International  Council  on  Systems  Engineering  (INCOSE)  and  Institute  of 
Electrical  and  Electronics  Engineers  (IEEE),  have  agreed  to  become  joint  stewards  of  the 
BKCASE  products  once  they  are  released  in  2012.  Both  INCOSE  and  the  IEEE  are  partners 
in  the  current  project  and  have  provided  observers  and  authors  to  the  BKCASE  team.  Other 
partners  and  sponsoring  organizations  include  the  Association  for  Computing  Machinery 
(ACM)  and  the  Systems  Engineering  Division  (SED)  of  the  National  Defense  Industrial 
Organization.  Plans  are  underway  to  continue  to  identify  and  address  gaps  in  the  SEBoK 
through  the  stewardship  of  these  organizations. 

Summary 

In  this  paper  we  have  examined  the  gaps  between  community  needs  and  the  SEBoK  version 
0.5  knowledge  base.  In  particular  we  have  explored  unmet  needs  in  1)  related  disciplines  and 
2)  emerging  systems  engineering  topics.  Although  there  is  no  consensus  on  what  knowledge 
from  related  disciplines  should  be  included  in  the  SEBoK,  it  is  clear  that  a  systems 
engineering  specific  treatment  of  certain  areas  of  knowledge  in  some  adjacent  disciplines 
would  be  useful  to  the  SE  community.  We  have  described  a  set  of  topics  in  Software 
Engineering,  Project  Management,  and  Specialty  disciplines  that  are  currently  missing  but 
that  would  provide  conceptual  bridges  for  SE's  in  multidisciplinary  teams.  We  do  not  suggest 
that  these  are  the  only  areas  in  which  such  SE  specific  treatments  could  be  useful,  however, 
we  have  provided  examples  that  illustrate  topics  for  which  bridging  articles  could  be 
integrated  into  the  SEBoK. 
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